Managing Patient Consent in a Master Patient Index

ABSTRACT

A system and method for managing patient consent. A data access manager includes a controller, a lookup module, a clinical authorization engine, a logging/auditing unit, a user profile engine, a report module and a user interface engine. The controller manages the core functions and the transmission of data between the data access manager components. The lookup module enables a user to query patient data. The clinical authorization engine authorizes access to patient data. The logging/auditing unit logs and monitors user activity. The user profile engine accesses and updates user profile information. The patient profile engine accesses and updates patient profile information. The report module generates reports related to the user activity. The user interface engine generates user interfaces for displaying the user profiles and patient information data.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 USC §120 to U.S. patentapplication Ser. No. 13/346,721, entitled “Managing Patient Consent in aMaster Patient Index,” filed Jan. 9, 2012, which is continuation acontinuation-in-part, under 35 USC §120, of U.S. patent application Ser.No. 11/416,666, entitled “System and Method for Using and Maintaining aMaster Matching Index,” filed May 2, 2006, which claims benefit under 35USC §119(e) to U.S. Provisional Application No. 60/577,754, entitled“System and Method for Using and Maintaining a Master Matching Index,”filed May 3, 2005, the entirety of each of which is hereby incorporatedby reference.

BACKGROUND

1. Field of the Invention

The invention relates to managing patient consent. In particular, theinvention relates to a system for managing patient consent for accessingpatient information in a Master Patient Index.

2. Description of the Related Art

Providing quality health care and related services (e.g., pharmaceuticalservices, veterinary services) depends on having the ability to reliablyaccess various types of records. In the case of patients, informationregarding a particular patient may be needed by various different typesof health care related entities. For example, any one a hospital, ahealth care organization, a clinic or hospital lab, an insurancecompany, or a pharmacy may need access to particular computerizedpatient information. Such information retrieval generally occurs byquerying a database associated with the health care related entityperforming the query. The database typically contains all or part ofwhat is referred to as a “Master Patient Index” (MPI), which is acollection of patient information and identifiers. Particularly, an MPIis a collection of indexed patient records, where each record containsinformation about a particular patient. In practice, user-levelapplications submit known or believed patient information to thedatabase, which then uses the MPI to match the incoming data withinformation stored in the database. If a match is found, the record (orpointer thereto) is returned to the querying entity.

While a typical MPI is designed to work within or for a particularhealth care related entity (e.g., a single hospital, a medical group),including among disparate information systems across the health carerelated entity, the increased mobility of individuals throughout theoverall health care system and the constant evolution of health care ingeneral requires that patient information be reliably accessible by alocal, state, regional or national community of health care relatedentities.

A problem arises when a physician accesses patient data for a patientthat the physician has not yet been assigned. For example, when anemergency room physician treats a patient, the physician needs thepatient's medical records without the delay that is incurred when thehospital goes through the normal routines of assigning the patient tothe physician. This access to the patient's medical information isreferred to as “breaking glass.” Once the emergency is addressed,problems arise with whether the physician continues to have access tothe medical records, whether there is an opportunity for abusing thissystem and whether there should be additional protection of patientinformation for patients that are public figures.

SUMMARY OF THE INVENTION

The technology described in the invention overcomes the deficiencies andlimitations of the prior art at least in part by providing a system andmethod for managing patient consent. The data access manager managespatient consent and user access to patient information. The data accessmanager receives patient information from a plurality of sources such asa Master Matching Index (MMI), a data retrieval service, healthcare datastore, health care related entities, etc. The data access managerdetermines whether a user requesting the patient information is allowedto access the patient information.

In one embodiment, a MMI includes a collection of patient informationand identifiers. An MMI adapter is coupled to the MMI for sendingqueries to the MMI for a health related entity. The MMI adaptercomprises a data access manager that includes a controller, a lookupmodule, a clinical authorization engine, a logging/auditing unit, apatient profile engine, a user profile engine, a report module and auser interface engine. The controller manages the core functions and thetransmission of data between the data access manager components. Thelookup module enables a user to query patient data. The clinicalauthorization engine authorizes access to patient data. Thelogging/auditing unit logs and monitors user activity. The user profileengine accesses and updates user profile information. The patientprofile engine accesses and updates patient profile information. Thereport module generates reports related to user activity. The userinterface engine generates user interfaces for displaying the userprofiles, patient profiles and patient data.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated by way of example, and not by way oflimitation in the figures of the accompanying drawings in which likereference numerals are used to refer to similar elements.

FIG. 1 is a high-level block diagram illustrating a system tor managingpatient consent according to one embodiment of the invention.

FIG. 2 is a block-diagram of a data access manager according to oneembodiment of the invention.

FIG. 3A is a graphical illustration of a user interface for designatingpatient consent according to one embodiment of the invention.

FIG. 3B is a graphical illustration of a user interface for designatinguser rights according to one embodiment of the invention.

FIG. 3C is a graphical illustration of a user interface for accessingpatient data according to one embodiment of the invention.

FIG. 3D is a graphical illustration of a user interlace for accessingconfidential patient information according to one embodiment of theinvention.

FIG. 4 illustrates a flowchart of a method for managing patient consentaccording to one embodiment of the invention.

FIG. 5 illustrates a flowchart of a method for monitoring user access topatient information according to one embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A system and method for managing patient consent are described below. Inthe following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the invention. It will be apparent, however, to oneskilled in the art that the technology described in the various exampleembodiments can be practiced without these specific details. In otherinstances, structures and devices are shown in block diagram form inorder to avoid obscuring the invention.

Reference in the invention to “one embodiment,” “an embodiment” or “anexample embodiment” means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the description. The appearances of thephrase “in one embodiment” in various places in the invention are notnecessarily all referring to the same embodiment.

Embodiments of the present invention generally relate to a MasterMatching Index (MMI). An MMI is an index of records or information thatmay be matched against queries submitted from across a community ofentities needing information of the type contained in the MMI. Thecommunity of entities coupled to a particular MMI is herein referred toas an MMI-based system or network. In one or more embodiments, anMMI-based network (or system) and method allows different entities toaccess a central MMI via matching management specific to each of theentities. In other words, an entity in the network may tune its matchingalgorithm(s) for improved matching accuracy without affecting thematching accuracy of other entities in the network.

It is noted that the scope of the present invention is not limited tomatching patient records as is done with an entity-specific MasterPatient Index (MPI). Rather, the principles of the present invention areequally applicable to any type of matching index. For example, an MMI inaccordance with one or more embodiments may contain patient records asis done with an MPI. In one or more other embodiments, an MMI maycontain information relating to physicians. For example, such an MMI maymatch against name, Drug Enforcement Administration (DEA) number and/ortype. Further, in one or more embodiments, an MMI may containinformation relating to insurance plans. For example, such an MMI maymatch against a plan number and/or address for submission of insuranceclaims. Further, in one or more embodiments, an MMI may containinformation relating to pharmacies. For example, such an MMI may matchqueries against addresses, phone numbers, and/or type. Further, in oneor more embodiments, an MMI may contain information relating toveterinary care. For example, such an MMI may match queries againstanimal records (e.g., state tag number, last known home address).Further, in one or more embodiments, an MMI may contain informationrelating to product inventory. For example, such an MMI may containinformation relating to product weight, cost, type, and/or use. Thus,although one or more embodiments are described below with reference tomatching patient records, it is to be understood that any type of MMImay be used similarly, at least with respect to the distributive,matching and process flow aspects described herein.

Some portions of the detailed descriptions that follow are presented interms of algorithms and symbolic representations of operations on databits within a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self consistent sequence of steps leading to a desiredresult. The steps are those requiring physical manipulations of physicalquantities. Usually, though not necessarily, these quantities take theform of electrical or magnetic signals capable of being stored,transferred, combined, compared, and otherwise manipulated. It hasproven convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computer system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computer system's registers andmemories into other data similarly represented as physical quantitieswithin the computer system memories or registers or other suchinformation storage, transmission or display devices.

The present embodiment of the invention also relates to an apparatus forperforming the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may comprise ageneral-purpose computer selectively activated or reconfigured by acomputer program stored in the computer. Such a computer program may bestored in a computer readable storage medium, such as, but is notlimited to, any type of disk including floppy disks, optical disks,CD-ROMs, and magnetic disks, read-only memories (ROMs), random accessmemories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flashmemories including USB keys with non-volatile memory or any type ofmedia suitable for storing electronic instructions, each coupled to acomputer system bus.

The invention can take the form of an entirely hardware embodiment, anentirely software embodiment or an embodiment containing both hardwareand software elements. In a preferred embodiment, the invention isimplemented in software, which includes but is not limited to firmware,resident software, micode, etc.

Furthermore, the invention can take the form of a computer programproduct accessible from a computer-usable or computer-readable mediumproviding program code for use by or in connection with a computer orany instruction execution system. For the purposes of this description,a computer-usable or computer readable medium can be any apparatus thatcan contain, store, communicate, propagate, or transport the program foruse by or in connection with the instruction execution system,apparatus, or device.

A data processing system suitable for storing and/or executing programcode will include at least one processor coupled directly or indirectlyto memory elements through a system bus. The memory elements can includelocal memory employed during actual execution of the program code, bulkstorage, and cache memories which provide temporary storage of at leastsome program code in order to reduce the number of times code must beretrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards,displays, pointing devices, etc.) can be coupled to the system eitherdirectly or through intervening I/O controllers.

Network adapters may also be coupled to the system to enable the dataprocessing system to become coupled to other data processing systems orremote printers or storage devices through intervening private or publicnetworks. Modems, cable modem and Ethernet cards are just a few of thecurrently available types of network adapters.

Finally, the algorithms and displays presented herein are not inherentlyrelated to any particular computer or other apparatus. Variousgeneral-purpose systems may be used with programs in accordance with theteachings herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear from thedescription below. In addition, the invention is not described withreference to any particular programming language. It will be appreciatedthat a variety of programming languages may be used to implement theteachings of the invention as described herein.

System Overview

FIG. 1 illustrates a block diagram of a system 100 for managing patientconsent in a Master Patient Index according to one embodiment of theinvention. In FIG. 1 and the remaining figures, a letter after areference number, such as “125 a” is a reference to the element havingthat particular reference number. A reference number in the text withouta following letter, such as “125,” is a general reference to any or allinstances of the element bearing that reference number. In theillustrated embodiment, these entities are communicatively coupled via anetwork 105.

The illustrated description of a system 100 for managing patient consentincludes distributed MMI adapters 115 a, 115 b . . . 115 n that areaccessed by health care related entities 125 a, 125 b . . . 125 n,health care data stores 130 a . . . 130 n and an MMI 101. In theillustrated embodiment, these entities are communicatively coupled via anetwork 105. The MMI adapters 115 a, 115 b . . . 115 n in FIG. 1 areused by way of example. While FIG. 1 illustrates three MMI adapters 115a, 115 b . . . 115 n, the description applies to any system architecturehaving one or more MMI adapters 115 n. MMI adapter 115 a is coupled tothe network 105 via signal line 108. A health care related entity 125 aaccesses the MMI adapter 115 a via signal line 110. MMI adapter 115 b iscoupled to the network 105 via signal line 112. A health care relatedentity 125 b accesses the MMI adapter 115 b via signal line 116.

In one embodiment, the MMI adapter 115 a is a hardware server, such asone powered by Medicity®. The MMI adapters 115 a, 115 b . . . 155 nserver as interfaces to health care entities 125 a, 125 b . . . 125 n.Those skilled in the art will note that while a distributed MMI adapter115 and its associated health care related entity 125 may reside on thesame system, this need not always be the case. For example, in one ormore embodiments, the distributed MMI adapter 115 may be provided as aremote interface to the associated health care related entity 125.

The MMI adapter 115 a comprises a data access manager 103 a and astorage device 141. The MMI adapter 115 b comprises a data accessmanager 103 b and a storage device (not shown). The data access managers103 a, 103 b manage patient consent and user access to healthcareinformation. The storage device 141 stores data managed by the dataaccess manager 103 a, such as the identity of users and their patientconsent forms.

The health care entities 125 maintain separate systems with their owninformation and access patient information stored by other entities viathe network 105. Health care entities 125 include, but are not limitedto, a hospital, a specific department within a hospital (e.g.,admissions, laboratory, radiology), a clinic, a physician's office, apharmacy, a health insurance company, a health care organization (e.g.,a Health Maintenance Organization (HMO), a hospital-associated researchlab, etc. A health care related entity 125 needing to locate aparticular patient record submits a query to the respective MMI adapter115. The query is embodied in a thread configured by the respective MMIadapter 115 and the thread is transmitted to the MMI 101. Thus, when oneof the health care related entities 125 submits a query for a patientrecord, the query is actually sent as a set of instructions describinghow to look for the patient record in the MMI 101.

The MMI 101 includes a collection of patient information. For example,the MMI 101 is a collection of indexed patient records, where eachrecord includes a patient identifier which uniquely identifies a patientand data associated with a patient identifier describing health careinformation associated with the patient identified by the patientidentifier. The MMI 101 is coupled to the network 105 via signal line104. In one embodiment, the MMI 101 comprises a computing device, suchas a server, desktop computer or laptop, including a database having oneor more patient identifiers and data associated with a patientidentifier describing health care data, such as test results,demographic information, billing information, prescription history orsimilar data associated with the patient identifier.

In another embodiment, the MMI 101 includes a data retrieval servicethat fulfills data request and one or more health care data stores 130 a. . . 130 n that includes health care data associated with the patientidentifier. Therefore, the MMI 101 matches data from the data retrievalservice with one or more patients, allowing retrieval of health caredata associated with a patient from a database stored on the MMI 101 orfrom a health care data store 130 identified by the MMI 101. Although,the data retrieval service is described as part of the MMI 101, invarious embodiments, the MMI 101 and the data retrieval service 107 areon separate servers.

One or more health care data stores 130 a . . . 130 n communicate withthe MMI 101. A health care data store 130 a comprises a computing deviceor other storage device including health care data, such as clinicalresults, prescription history, insurance or billing information,demographic information or other data associated with providing healthcare services or products to a patient. For example, health care datastore 130 a comprises a clinical data catalog including clinical data, amedical insurance database including billing information for one or morepatients, a record database including demographic information associatedwith one or more patients or other store of information applicable tohealth care services or products provided to one or more patients.Therefore, a health care data store 130 a includes health care dataassociated with one or more patients, allowing retrieval of dataassociated with a particular patient. The health care data store 130 ais coupled to the network 105 via signal line 114. In one embodiment,the health care data storage 130 is stored locally with the health carerelated entity 125.

The network 105 is a conventional type, wired or wireless, and may haveany number of configurations such as a star configuration, token ringconfiguration or other configurations known to those skilled in the art.Furthermore, the network 105 may comprise a local area network (LAN), awide area network (WAN) (e.g., the internet), and/or any otherinterconnected data path across which multiple devices may communicate.In yet another embodiment, the network 105 may be a peer-to-peernetwork. The network 105 may also be coupled to or includes portions ofa telecommunications network for sending data in a variety of differentcommunication protocols. In yet another embodiment, the network 105includes Bluetooth communication networks or a cellular communicationsnetwork for sending and receiving data such as via short messagingservice (SMS), multimedia messaging service (MMS), hypertext transferprotocol (HTTP), direct data connection, WAP, email, etc.

Data Access Manager 303

Referring now to FIG. 2, the MMI adapter 115 comprises a data accessmanager 103, a memory 237, a processor 235, a communication unit 245 anda storage device 141 that are each connected to the bus 220. The bus 220may represent one or more buses including an industry standardarchitecture (ISA) bus, a peripheral component interconnect (PCI) bus, auniversal serial bus (USB), or some other bus known in the art toprovide similar functionality.

The processor 235 comprises an arithmetic logic unit, a microprocessor,a general purpose controller or some other processor array to performcomputations and provide electronic display signals to a display device.The processor 235 is coupled to the bus 220 for communication with theother components via signal line 236. Processor 235 processes datasignals and may comprise various computing architectures including acomplex instruction set computer (CISC) architecture, a reducedinstruction set computer (RISC) architecture, or an architectureimplementing a combination of instruction sets. Although only a singleprocessor is shown in FIG. 2, multiple processors may be included. Theprocessing capability may be limited to supporting the display of imagesand the capture and transmission of images. The processing capabilitymight be enough to perform more complex tasks, including various typesof feature extraction and sampling. It will be obvious to one skilled inthe art that other processors, operating systems, sensors, displays andphysical configurations are possible.

The memory 237 stores instructions and/or data that may be executed byprocessor 235. The memory 237 is coupled to the bus 220 forcommunication with the other components via signal line 238. Theinstructions and/or data may comprise code for performing any and/or allof the techniques described herein. The memory 237 may be a dynamicrandom access memory (DRAM) device, a static random access memory (SRAM)device, flash memory or some other memory device known in the art. Inone embodiment, the memory 237 also includes a non-volatile memory orsimilar permanent storage device and media such as a hard disk drive, afloppy disk drive, a CD-ROM device, a DVD-ROM device, a DVD-RAM device,a DVD-RW device, a flash memory device, or some other mass storagedevice known in the art for storing information on a more permanentbasis.

The communication unit 245 transmits and receives data to and from theMMI 101, health care data stores 130 a . . . 130 n and other MMIadapters 115. The communication unit 245 is coupled to the bus 220 viasignal line 246. In one embodiment, the communication unit 245 includesa port for direct physical connection to the MMI 101 or to anothercommunication channel. For example, the communication unit 245 includesa USB, SD, CAT-5 or similar port for wired communication with the userdevice 115. In another embodiment, the communication unit 245 includes awireless transceiver for exchanging data with the MMI 101 or any othercommunication channel using one or more wireless communication methods,such as IEEE 802.11, IEEE 802.16, BLUETOOTH® or another suitablewireless communication method.

In yet another embodiment, the communication unit 245 includes acellular communications transceiver for sending and receiving data overa cellular communications network such as via short messaging service(SMS), multimedia messaging service (MMS), hypertext transfer protocol(HTTP), direct data connection, WAP, e-mail or another suitable type ofelectronic communication. In still another embodiment, the communicationunit 245 includes a wired port and a wireless transceiver. Thecommunication unit 245 also provides other conventional connections tothe network for distribution of files and/or media objects usingstandard network protocols such as TCP/IP, HTTP, HTTPS and SMTP as willbe understood to those skilled in the art.

In one embodiment, the data access manager 103 comprises a controller201, a lookup module 202, a clinical authorization engine 203, a reportmodule 205, a logging/auditing unit 207, a user profile engine 212 and auser interface engine 213.

The controller 201 is software including routines for managing the corefunctions of the data access manager 103 and for transmitting data tothe different components. In one embodiment, the controller 201 is a setof instructions executable by the processor 235 to provide thefunctionality below for managing access to data. In another embodiment,the controller 201 is stored in the memory 237 and is accessible andexecutable by the processor 235. In either embodiment, the controller201 is adapted for cooperation and communication with the processor 235and other components of the data access manager 103 via signal line 230.

In one embodiment, the controller 201 performs core functions bylistening for data by listening to ports, scanning folders, etc.;inserting data into locations such as a TCP port, folders, etc.; parsingby converting incoming data into objects, such as Java objects;analyzing by examining objects to determine actions; saving data bycreating a new topic or adding to a topic that is saved in the storagedevice 141; formatting by rendering data into the required format, suchas by mapping, translating and grouping; sending packages of informationfor distribution and notifying by, for example, sending an email or aWeb alert in response to an event occurring.

The lookup module 202 is software including routines for enabling a user(via a client device) or a third-party application to query data. In oneembodiment, the lookup module 202 is a set of instructions executable bythe processor 235 to provide the functionality below for receiving arequest from a user for patient data, transmitting a query to a MMI 101or one or more health care data stores 130 a . . . 130 n and receivingpatient data from the MMI 101 or one or more health care data stores 130a . . . 130 n. In another embodiment, the lookup module 202 is stored inthe memory 237 and is accessible and executable by the processor 235. Ineither embodiment, the lookup module 202 is adapted for cooperation andcommunication with the processor 235 and other components of the dataaccess manager 103 via signal line 232.

In one embodiment, the lookup module 202 may be used totransform/translate incoming data from an associated health care relatedentity to a data format specified or otherwise accurately recognizableby the MMI 101. For example, in a case where the associated health careentity stores dates in month/day/year format and the MMI 101 managesdates in day/month/year format, the lookup module 202 may perform theproper date format conversion between the associated health care relatedentity and the MMI 101. Further, in another example, informationspecified with dashes (e.g., insurance identifies, social securitynumbers) may be converted by the lookup module 202 to a format withoutdashes (and vice-versa) depending on how data is stored in the MMI 101.

Moreover, the lookup module 202 may be used to resolve competingreturned matches. For example, if the MMI 101 is unable to automatedlymatch a patient against records, multiple possible matches may bereturned to the lookup module 202, in which case, the lookup module 202may be used to select one of the returned possible matches. In one ormore embodiments, the lookup module 202 may be manually used by a userto resolve a mismatch or multiple returned matches. Further, in one ormore embodiments, the lookup module 202 may be configured toautomatically resolve a mismatch or multiple returned matches based onsome predetermined logic.

Further, the lookup module 202 may be used for the generation of thealgorithms/rules for filtering patient data from the MMI 101. This maybe accomplished by using performing patient matching with known sampledata (representing data from the associated health care related entity).For example, sample data representing 10 known patients may be patientmatched, and then, using the lookup module 202, a determination may bemade for generating or adjusting algorithms/rules in the lookup module202 to improve matching accuracy. Thus, in general, such “training”essentially comprises a feedback loop involving feeding sample data andtesting patient matching results to adjust the lookup module 202.Further, in one or more embodiments, the sample data may be periodicallyor regularly changed so as to test different algorithms/rules in thelookup module 202. Further still, in one or more embodiments, thealgorithms/rules in the lookup module 202 may be adjusted, whereuponsample data is patient matched to aid in determining whichalgorithms/rules result in a desired level of patient matching.

The clinical authorization engine 203 is software including routines forauthorizing access to and retrieving patient data from the storagedevice 141 or the master matching index 101. In one embodiment, theclinical authorization engine 203 is a set of instruction executable bythe process 235 to provide the functionality below for determiningwhether a user can access or update patient data. In another embodiment,the clinical authorization engine 203 is stored in the memory 237 and isaccessible and executable by the processor 235. In either embodiment,the clinical authorization engine 203 is adapted for cooperation andcommunication with the processor 235 and other components of the dataaccess manager 103 via signal line 234. The clinical authorizationengine 203 supports reading data in one or more formats. For example,the clinical authorization engine 203 supports data formats includingHealth Level Seven (HL7) and extensible Markup Language (XML).

The clinical authorization engine 203 determines whether a user or athird-party application has a right or rights to access a patient data.In one embodiment, the clinical authorization engine 203 receivespatient information from the lookup module 202 and analyzes the patientinformation. The clinical authorization engine 203 analyzes theinformation by examining an indicator in the information. The indicatorindicates whether a patient opted-in to sharing patient information(with or without exceptions) that is associated with the patient orwhether the patient opted-out (with or without restrictions). In oneembodiment, the indicator is associated with the patient and theindicator applies to all information associated with the patient. Forexample, the clinical authorization engine 203 receives an indicatorthat indicates a patient opted-in to sharing the patient's informationwith other health care entities 125 in the network 105. Therefore, allhealth care data, such as clinical results, prescription history,insurance or billing information, demographic information or other dataassociated with providing health care services or products to a patientis accessible to a user that queried the patient. In some embodiments,the physician that generates the health care data controls theindicator. For example, a psychiatrist chooses whether the psychiatristsnotes are accessible to other physicians in the system. In some otherembodiments, the clinical authorization engine 203 applies stateregulations to the opt-in rules regardless of patient consent, such aswhen a state law prohibits sharing information of minors.

In another embodiment, the indicator is associated with at least a partof clinical data associated with a patient. For example, a patient optednot to share lab work results from the patient's general doctor with aspecialist that the patient sees. The clinical authorization engine 203examines the indicator and determines that the specialist does not haverights to access the lab work results. In yet another embodiment, theindicator is based on the type of data. For example, the type of datamay be a pregnancy test for a teen or a Human immunodeficiency virus(HIV) test for a person. In the embodiment, the clinical authorizationengine 203 comprises a catalog of data that includes types of data thata user cannot view unless the user has special privileges to view thedata.

In yet another embodiment, the clinical authorization engine 203authorizes access to patient data based on a relationship between theuser or a third-party application and the patient. For example, the useris a primary care physician for the patient or a person associated withthe physician and the data is lab work for the patient. Therefore, theclinical authorization engine 203 grants access to the lab work becausethe user has an authorized relationship with the patient. The clinicalauthorization engine 203 manages authorization based on direct andindirect documentation where a recorded patient consent form is directand relationships indicated through HL7 transactions are indirect. HL7transactions normally identify the requesting doctor or organizationalcomponent. This information is an indirect consent for the doctor ororganizational component to access unrestricted portions of a patient'shealth record. Given the nature of HIE environments, this may be theprimary method of authorizing access to patient information.

In yet another embodiment, the clinical authorization engine 203 deniesaccess to patient data based on a status associated with the patient.For example, Very Important People (VIPs) such as high ranking corporateemployees, diplomats, government officials, celebrities, etc. can have acertain status that protects the patient data from being widelydistributed. For example, a government official or a celebrity'sinformation is inaccessible because they are public figures. Categoriesand levels associated with confidential or VIP restrictions on patientdata include: business, clinician, individual, low, normal, restricted,very restricted, employee, unwed mother, substance abuse related, HIVrelated, psychiatry related, sexual and domestic violence related,celebrity, sensitive and taboo.

In one embodiment, the clinical authorization engine 203 givesphysicians and staff associated with the provider access to all patientdata after the user breaks the glass. In another embodiment, theclinical authorization engine 203 restricts all or part of a patientrecord if the patient is a VIP or the patient data is marked as beingconfidential. In another embodiment, the clinical authorization engine203 restricts access to confidential information to users with theappropriately high security level. A user can request restriction ofaccess to their patient information. For example, the staff cannotaccess information about a patient's pregnancy test or HIV test if thestaff is not associated with the patient or provider. In yet anotherembodiment, the physicians can see all information for a VIP but thestaff is limited from accessing all information. In yet anotherembodiment, the clinical authorization engine 203 prevents the user fromaccessing patient information because the time limit for providingaccess to the patient data has expired.

The clinical authorization engine 203 marks patient data as beingassociated with a VIP or as confidential in response to receiving amessage indicator. The message indicator can be sent in a HL7 segment.Depending upon the type of HL7 segment, all or a portion of the patientdata is marked as being confidential. For example, the authorizationengine 203 receives an HL7 transaction with a patient data 1 (PD1)segment for flagging the entire patient record with a VIP status and, inresponse, the authorization engine 203 prevents the patient record fromappearing in search results unless the user has security rights to viewVIP status or the user is a physician for the patient. The clinicalauthorization engine 203 does not remove the VIP status unless therequest for removal is received from the same source that originallysent the VIP status.

In another example, only a portion of the patient record is marked ashaving a VIP status when the clinical authorization engine 203 receivesan HL7 transaction where the VIP indicator is at the encounter level ina patient visit 2 (PV2) segment or it is sent as a confidentialdiagnosis in a diagnosis 1 (DG1) segment. A VIP status sent at theencounter level removes everything associated with a specific encounterfrom view (including orders, results, reports, notes, diagnosis, etc.)unless the user has the security rights to view VIP information or is aphysician for the encounter. Everything else in the patient's recordremains visible.

In yet another example, an order and not the patient's entire record ismarked as having a VIP status when the clinical authorization engine 203receives a common order segment (ORC). The clinical authorization engine203 assigns the order and everything associated with the order asconfidential and renders the order unsearchable unless the user hassecurity rights to view confidential information or is the physician onthe order.

In yet another embodiment, the clinical authorization engine 203receives a request from a user or a third-party application foremergency access to data that a patient has not consented to sharing. Inthis embodiment, the user exercises a break glass policy to accesspatient information. Breaking glass refers to the act of a physicianaccessing a patient's information when the physician has not yet beenassigned to the patient and/or the patient has not given consent toaccess all or part of the patient's clinical data. As a result, even ifthe patient opted out of having the patient's data shared amongphysicians and/or staff, the breaking glass overrides the opt-outoption.

For example, in a public health emergency where there is an emergencydisease outbreak or a natural disaster, a physician may need access topatient data, such as clinical history, medications, lab work etc. totreat the patient. Alternatively, the physician may need to ignorepatient consent and identify effected patients during an emergency, suchas a disease outbreak. The clinical authorization engine 203 transmitsthe requested data during the emergency. In one embodiment, the clinicalauthorization engine 203 records the reason for breaking glass,including the nature of the emergency and whether the breaking glass wasprompted by reporting information to public health officials as requiredby law. In one embodiment, the breaking glass policy includes an optionfor automatically giving a group of physicians access to patientinformation during an emergency, such as a hurricane. This is referredto as a Health Information Exchange (HIE)-wide emergency override. Otherbreaking glass examples occur when the physician needs the patient'sinformation and it is difficult to request permission, such as when thephysician is acting as a consultant for the patient's primary physician.

In one embodiment, the clinical authorization engine 203 grants accessto all or part of patient data. In another embodiment, the clinicalauthorization engine 203 requires at least one of a provider or aphysician that accesses the data, an access period and a reason foraccessing data from the user. The identity of the requestor can befurther identified as an attending, admitting or consulting physician orstaff, which is used to associated a nurse or other healthcare providerwith a patient. In yet another embodiment, the clinical authorizationengine 203 instructs the user interface engine 213 to generate graphicaldata of a patient consent form that that patient must print and signbefore access is granted. The clinical authorization engine 203transmits information about the location of the physical document to thelogging/auditing unit 207, which logs the location as part of theconsent authorization documents.

Once the clinical authorization engine 203 grants the user or thethird-party application access to the patient data, the clinicalauthorization engine 203 stores the request and/or the requiredinformation in storage device 141 and notifies the lookup module 202that the patient's data can be present in search results for the periodof time that the patient's data is accessible to the user. The user canaccess the patient data one time, in a limited capacity, is stopped fromfurther accessing the data or at a later time if the time is still inthe access period. In one embodiment, the breaking glass policy is onlyprovided to certain users or users associated with certain roles. Forexample, the physician has access to a policy in an emergency situation.However, regular staff would not be permitted to use the policy.

In some instances, the clinical authorization engine 203 performsanonymizing and de-identifying of the patient data. This data can thenbe used for clinical trials and other methods without having to beconcerned about patient consent because the data is anonymous. In manycircumstances, the patients are still notified that their informationcould be used anonymously so that the patients have informed consent. Inanother embodiment, the clinical authorization engine 203 also generatesan identifier linking the information back to the original patient. Theclinical authorization engine 203 can later identify the user through arestricted identification process. In this embodiment, the clinicalauthorization engine 203 may employ the same restrictions for patientconsent and breaking glass that are described above.

The logging/auditing unit 207 is software including routines for loggingand monitoring user activity. In one embodiment, the logging/auditingunit 207 is a set of instructions executable by the processor 235 toprovide the functionality below for tracking data access. In anotherembodiment, the logging/auditing unit 207 is stored in the memory 237and is accessible and executable by the processor 235. In eitherembodiment, the logging/auditing unit 207 is adapted for cooperation andcommunication with the processor 235 and other components of the dataaccess manager 103 via signal line 239.

The logging/auditing unit 207 creates a common event log to record eachtime a user accesses or modifies a patient record or piece of clinicalinformation. For example, the logging/auditing unit 207 tracks when auser changes or adds patient/clinical data. In another example, thelogging/auditing unit 207 logs user activity when a userqueries/requests patient data or views the patient data. Thelogging/auditing unit 207 logs the user identifier and context, theevent data and time, the event type, the patient identified and context,the encounter context, the data type, the data descriptor andevent-specific information. The logging/auditing unit 207 stores theuser activity in storage device 141. Those skilled in the art will notethat other user activities are recorded by the logging/auditing unit207. The storage device 141 is coupled to the bus 220 via signal line248.

In another embodiment, the logging/auditing unit 207 determinesinappropriate data access by a user. The logging/auditing unit 207analyzes data access to determine patterns of inappropriate access bythe user. For example, the logging/auditing unit 207 determines that auser broke glass too many times over a predetermined threshold for aperiod of time. In another embodiment, the logging/auditing unit 207determines that a user broke glass too many times on certain types ofpatients. For example, the user broke glass too many times for VIPs,such as celebrities, etc.

The user profile engine 212 is software including routines for accessinguser profile information. In one embodiment, the user profile engine 212is a set of instructions executable by the processor 235 to provide thefunctionality below for accessing and updating user profiles. In anotherembodiment, the user profile engine 212 is stored in the memory 237 andis accessible and executable by the processor 235. In either embodiment,the user profile engine 232 is adapted for cooperation and communicationwith the processor 235 and other components of the data access manager103 via signal line 244.

The user profile engine 232 registers users. The user profile engine 232identifies users with a user identifier, classifies users by type andauthenticates the users with a password and an optional second factorsuch as a token-based authentication (e.g. biometric, RFID, etc.). Theuser profile 212 includes an option for a patient to have access totheir information be limited because the patient is a VIP. User namescan be assigned by an administrator or self-assigned during a selfapplication or security administrator. If self-assigned, the userprofile engine 212 creates the user profile and places it in a workqueue for review by the healthcare entity's required process. The userprofile engine 212 classifies users by a type that defines a basic setof functional and data type access authorities. Many of these securityattributes can be adjusted individually to create users with authorityprofiles that have been tailored to meet user and environment specificneeds. The user profile engine 212 assigns passwords or the userspecifies the password.

The user profile engine 212 transmits instructions for the userinterface engine 213 to generate graphical data for displaying a userinterface to the user for registering the user. The user profile engine212 then receives user profile information from a user interface engine213. In the embodiment, the user profile information is for at least oneof updating or adding a user profile. The user profile informationincludes information for allowing or denying access to patientinformation. For example, the patient can opt-in to having the patient'sinformation exchanged over the network 105 by providing an affirmativeauthorization by signing a consent form. The patient can also opt-inwith restrictions, such as identifying types of information that thepatient wants kept confidential. The patient can also opt-out of havingthe patient's reformation exchanged over the network 105 by formallyrequesting that the data not be exchanged. The patient can also opt-outwithout exceptions, which results in the patient information beingexchanged and the consumer being notified through mailings, brochures,posted notices or other means.

The clinical authorization engine 203 retrieves user profile informationfrom the user profile engine 212 by sending a user identifier to theuser profile engine 212. In one embodiment, the storage device 141stores user profile information. The storage device 141 transmits theuser profile information to at least one of the clinical authorizationengine 203 and the user profile engine 212.

The report module 205 is software including routines for generatingreports. In one embodiment, the report module 205 is a set ofinstructions executable by the processor 235 to provide thefunctionality below for generating reports. In another embodiment, thepatient report module 205 is stored in the memory 237 and is accessibleand executable by the processor 235. In either embodiment, the reportmodule 205 is adapted for cooperation and communication with theprocessor 235 and other components of the data access manager 103 viasignal line 241.

The report module 205 generates reports related to user activity. Thereport module 205 generates a report based on information logged by thelogging/auditing unit 207. For example, the report module 205 generatesa report that is related to a history of user access to patientinformation. The report includes instances of breaking glass andinformation about patient consent including the patient consentdocuments discussed above with reference to the clinical authorizationengine 203. In one embodiment, the report module 205 generates thereport for regular review by a security officer and the report isforwarded to peer review or regulatory organizations for action asappropriate. In another embodiment, the report is displayed to anadministrator for determining whether inappropriate access by a useroccurred. In one embodiment, the report indicates how many times a userbroke glass during a period of time. In another embodiment, the reportindicates user access to a specific set of patients.

The report module 205 configures the report to include a variety of dataincluding: a user login history, physician logins, patient chart access,patient consent audit transactions, clinical Inbox activities, abreaking glass audit log, deliveries, patient merge clinical datarepositories, patient move/link MPIs, community document activities,medication history queries and organization or user rights logs. Theuser login history returns a login history for all users in a specifiedorganization, for a specified user or a number of active users in aspecified organization. The physician logins summarizes the annuallogins for all physicians in a single repository. The patient chartaccess provides patient chart access for all users in a specifiedorganization, for a specified patient or for a specified user. Thepatient consent audit transactions provides audit transactions for aspecified organization, for a specified patient or for a specified user.The clinical inbox activity summarizes clinical inbox actions taken byusers in a specified organization, summarized which users have takenaction on a specified patient's information from the clinical inbox orsummarizes which patients have had clinical inbox actions taken by aspecified user. The break glass audit log provides a break glass auditlog for long and short term uses for all the users in a specifiedorganization, for a specified user or a specified patient, and providesa list of who broke glass for a long or short term to see patients of aspecified provider. The delivery report identifies the delivery methodand location for each result for a specified organization or for eachresult for a specified patient. The patient move/link MPI reportsreturns move and link details by a user or provides a moves and linkssummary in response to manual input. The community document activitysummarizes continuity of care document (CCD) actions taken by users in aspecified organization, by which patients have had CCD actions taken bythe specified user or by which users have taken action on the specifiedpatient's information using CCDs. The medication history queriessummarizes medication history queries initiated by users in a specifiedorganization or by a specified user, and summarizes which users haveinitiated medication history queries on a specified patient. Theorganization and user rights log tracks who created or changedorganization or user rights as well as which users viewed managementreports.

In one embodiment, the report module 205 generates a report for publichealth officials of instances where a public health emergency occurred.The report contains a list of the people whose information was accessedin addition to any type of patient consent that is part of the record orinstances where the physician had to break glass to treat the patient.

Example User Interface Engine

The user interlace engine 213 is software including routines forgenerating graphical data for displaying a user interface. In oneembodiment, the user interface engine 213 is a set of instructionsexecutable by the processor 235 to provide the functionality below forgenerating a user interface. In another embodiment, the user interfaceengine 213 is stored in the memory 237 and is accessible and executableby the processor 235. In either embodiment, the user interface engine213 is adapted for cooperation and communication with the processor 235and other components of the data access manager 103 via signal line 243.

The user interface engine 213 generates a user interface according toinstructions received from the clinical authorization engine 203, thereport module 205 and the user profile engine 212. In one embodiment,the user interface engine 213 receives consent status from a third-partyapplication. The user opts-in with restrictions and opts-out withexceptions. The restrictions include a time limit, a provider and a datatype. The user interface engine 213 is described in more detail below inreference to FIGS. 3A-3D.

FIG. 3A is a graphic representation 300 of a user interface fordesignating patient consent. Graphic representation 300 displays patientinformation and options for designating patient consent. A user orpatient designates patient consent by selecting one of a first option302 to opt-in or a second option 304 to opt-out of sharing clinical dataassociated with the patient. In one embodiment, a patient does notdesignate an option to share clinical data and the designation isoverridden by a policy of the health care facility 125 b that providedservice to the patient. In FIG. 3A, the opt-out option 304 is thedefault policy for opting-out of sharing clinical data associated withthe patient

FIG. 3B is a graphic representation 310 of a user interface fordesignating user rights. Graphic representation 310 displays user rightsfor accessing patient data. The user id 311 indicates that the userrights are for user “jdoe.” The user is assigned a role value 312 thatsets default values for accessing patient data. In this embodiment, therole value 312 is staff but other options include attending, admittingand consulting physicians. In one embodiment, the default values areoverridden by options under user right options 313, 314 and 315.

Options 313 determine whether a user is allowed to access various typesof clinical data. For example, a user may be allowed to access lab work,medication history, pathology reports, etc. Options 314 determinewhether the user is allowed to access VIP patient data, confidentialorders and results and labs or accounts. Options 315 determines whetherthe user is allowed to access VIP status patient data, confidentialorders and results and labs or accounts under an emergency or breakglass situation.

FIG. 3C is a graphic representation 320 of a user interface foraccessing patient data. Graphical icon 321 indicates drat the userviewing the information does not have access to this patient's data and,as a result, would have to click on the graphical icon 321 to view thepatient data associated with the line. The user clicks the graphicalicon 321 to break glass to view the patient data. The user interfaceengine 213 receives the request and transmits the request to theclinical authorization engine 203 and the logging/auditing unit 207. Theclinical authorization engine 203 determines whether the user is allowedto access the patient data. The logging/auditing unit 207 logs thebreaking glass request. If the user is allowed to view the patient data,the user interface engine 213 generates a user interface that includesthe patient data.

Graphical icon 322 indicates that a user previously broke glass in orderto view patient data associated with patient in that row and the patientdata is accessible for a period of time. When the clinical authorizationengine 203 receives the request to break glass, the user has the optionto create a long term relationship with the patient. Therefore, the useris not required to subsequently break glass to access patient dataassociated with the patient at a later time.

Graphical icon 323 indicates that the user can break glass for patientsearch results. This could happen when a user searches for a patient andthe results fail to include the patient. By breaking glass on searchresults, the user can view patient records for patients that existoutside the user's security rights, such as patient records marked asVIP or confidential.

Graphical icon 324 indicates that the patient selected to opt-in withrestrictions to having data shared between organizations such that someof the information is inaccessible to the user.

FIG. 3D is a graphic representation 330 of a user interface foraccessing confidential patient records using a break glass policy.Graphic representation 330 displays a confidentiality alert 331 todisclose permitted uses of information and to disclose that the useraccess is monitored. In the example, the user is required to identify aprovider 332 that is treating the patient, an option for the timing ofaccessing the patient information and a reason 335 for accessing thepatient information, such as because the physician is being consultedfor a diagnosis. The user selects at least one of a one-time accessoption 333 and a long-term option 334. The long term option 334 requiresa date/time when the access expires.

Methods

Referring now to FIGS. 4 and 5, various example embodiments of theinvention will be described.

FIG. 4 is a method 400 illustrating one embodiment for managing patientconsent. The lookup module 202 queries for a patient information andreceives 402 patient information that includes both confidential dataand non-confidential data. In one embodiment, the clinical authorizationengine 203 determines the confidential data based on indicators in theinformation. The indicators are associated with at least one of thepatient and encounters associated with the patient. In the embodiment,the indicator is a value for opting-out of sharing patient data withdisparate health care information systems. In another embodiment, if thepatient does not indicate an opt-in or opt-out value, then a defaultsetting of a health care facility 125 b that provided patientservices/care to the patient is used to determine whether to share ornot share data. The health care facility 125 b has a policy to opt-in oropt-out by default. A user of a health care entity 125 a has access tothe data based on at least one of the indicators in the data and adefault opt-in/opt-out policy of health care entity 125 b.

The lookup module 202 instructs the user interface engine 213 togenerate a user interface that includes the non-confidential data.Therefore, the lookup module 202 hides the confidential data from theuser. The user interface engine 213 provides 404 the user interface tothe user. The clinical authorization engine 203 receives 406 a requestto access confidential data from the user. In one embodiment, the userrequests access using a break glass policy.

The clinical authorization engine 203 determines 408 whether the user isallowed to access to the confidential information. In one embodiment,the clinical authorization engine 203 determines whether the user isallowed to access the confidential information by determining a rolethat is assigned to the user in a user profile. For example, a user thatis assigned a role as a physician is allowed to use the break glasspolicy. If the user is part of the staff and not a physician, theclinical authorization engine 203 may also request a reason for why theuser wants to break glass. Reasons include: providing required medicalservice, transferring the patient to another facility, receiving arequest for consultation, the patient voluntarily seeking medicaltreatment, providing coverage for the patient's physician, needinginformation for billing purposes and treating a patient that is in theemergency room. In another embodiment, the clinical authorization engine203 determines an explicit setting that is associated with the userprofile. If the clinical authorization 203 determines that the user isnot allowed access, then the method 400 ends. If the clinicalauthorization 203 determines that the user is allowed access, then theuser interface engine 213 generates and provides 410 a user interfaceincluding the confidential data. The report module 205 generates 412 areport of user access of patient information.

Now turning to FIG. 5, a method 500 for monitoring user access topatient information is illustrated. The logging/auditing unit 207 logsand analyzes 502 patient information access by one or more users. Thelogging/auditing unit 207 determines 504 a pattern of the patientinformation access. The logging/auditing unit 207 determines 506 whetheran access violation or inappropriate access occurred based at least inpart on the patter. In one embodiment, the logging/auditing unit 207monitors how many times a particular user employs the break glass policyover a period of time and determines 506 that the user went over apredetermined threshold. In another embodiment, the user breaks anaccess threshold based on accessing a type of patient. For example, theuser uses the breaks glass policy over the predetermined threshold onVIPs. In one embodiment, the clinical authorization engine 203 applies amachine learning algorithm to the logs to identify suspicious behavior.If the logging/auditing unit 207 determines that there is not an accessviolation, then the method 500 ends. If the logging/auditing unit 207determines that there is an access violation, then the logging/auditingunit 207 reports 508 the access violation to an administrator. Forexample, the logging/auditing unit 207 generates an email or textmessage that alerts the administrator of the access violation.

The foregoing description of the example embodiments of the inventionhas been presented for the purposes of illustration and description. Itis not intended to be exhaustive or to limit the invention to theprecise form disclosed. Many modifications and variations are possiblein light of the above teaching. It is intended that the scope of thedisclosure be limited not by this detailed description, but rather bythe claims of this application. As will be understood by those familiarwith the art, the invention may be embodied in other specific formswithout departing from the spirit or essential characteristics thereof.Likewise, the particular naming and division of the modules, routines,features, attributes, methodologies and other aspects are not mandatoryor significant, and the mechanisms that implement the invention or itsfeatures may have different names, divisions and/or formats.Furthermore, as will be apparent to one of ordinary skill in therelevant art, the modules, routines, features, attributes, methodologiesand other aspects of the disclosure can be implemented as software,hardware, firmware or any combination of the three. Also, wherever acomponent, an example of which is a module, of the invention isimplemented as software, the component can be implemented as astandalone program, as part of a larger program, as a plurality ofseparate programs, as a statically or dynamically linked library, as akernel loadable module, as a device driver, and/or in every and anyother way known now or in the future to those of ordinary skill in theart of computer programming. Additionally, the disclosure is in no waylimited to implementation in any specific programming language, or forany specific operating system or environment. Accordingly, thedisclosure is intended to be illustrative, but not limiting, of thescope of the invention, which is set forth in the following claims.

What is claimed is:
 1. A computer-implemented method executed on one ormore processors for managing patient consent, the method comprising:receiving, with the one or more processors, private patient informationassociated with a health care information system of a provider;determining, with the one or more processors, that the private patientinformation includes confidential data based on an indicator, whereindata is confidential data when the indicator associated with the dataindicates that the data is inaccessible to a health care entity, thehealth care entity having an authorized relationship with the patient;receiving a request from a user for accessing the confidential data; anddetermining whether the user is allowed to access the confidential data.2. The method of claim 1, wherein the health care entity is anotherhealth care information system.
 3. The method of claim 1, wherein thehealth care entity is another health care provider.
 4. The method ofclaim 1, wherein the indicator is associated with at least one of apatient profile and an encounter associated with the patient profile. 5.The method of claim 1, further comprising: providing a confidentialityalert responsive to the user not being allowed to access theconfidential data, wherein the confidentiality alert requests a type ofaccess and a reason for accessing the confidential data, the reasonincluding an emergency permission; and ignoring patient consent toidentify affected patients during an emergency.
 6. The method of claim1, further comprising logging access activity of one or more users, thepatient information accessible by the one or more users and generating areport based on the access of the patient information.
 7. The method ofclaim 1, wherein determining whether the patient information includesconfidential data is based on whether a patient opted-in or opted-out ofexchanging the patient information.
 8. The method of claim 1, furthercomprising anonymizing the patient information and transmitting theanonymized patient information to the user without patient consent. 9.The method of claim 1, further comprising determining an age of thepatient and denying access to the patient information in accordance witha state law.
 10. The method of claim 1, further comprising: analyzingaccess of the confidential data determining a pattern of access of theconfidential data; and determining, based on the pattern, whether anaccess violation has occurred.
 11. A system for managing patientconsent, the system comprising: one or more processors; and a dataaccess manager stored on a memory and executable by the processor, thedata access manager receiving private patient information associatedwith a health care information system of a provider, determining thatthe private patient information includes confidential data based on anindicator, wherein data is confidential data when the indicatorassociated with the data indicates that the data is inaccessible to ahealth care entity, the health care entity having an authorizedrelationship with the patient, receiving a request from a user foraccessing the confidential data and determining whether the user isallowed to access the confidential data.
 12. The system of claim 11,wherein the health care entity is another health care informationsystem.
 13. The system of claim 11, wherein the health care entity isanother health care provider.
 14. The system of claim 11, wherein theindicator is associated with at least one of a patient profile and anencounter associated with the patient profile.
 15. The system of claim11, further comprising: a user interface engine stored on the memory andexecutable by the one or more processors, the user interface engine,responsive to the user not being allowed to access the confidentialdata, providing a confidentiality alert, the confidentiality alertrequesting a type of access and a reason for accessing the confidentialdata, the reason including an emergency permission; and wherein the dataaccess manager ignores patient consent to identity affected patientsduring an emergency.
 16. The system of claim 11, wherein the data accessmanager logs access activity of one or more users, the one or more usershaving access to the patient information and wherein the data accessmanager generates a report based on a plurality of access events by theone or more users.
 17. The system of claim 11, wherein determiningwhether the patient information includes confidential data is based onwhether a patient opted-in or opted-out of exchanging the patientinformation.
 18. The system of claim 11, wherein the data access manageranonymizes the patient information and transmits the anonymized patientinformation to the user without patient consent.
 19. The system of claim11, wherein the data access manager determines an age of the patient anddenies access to the patient information in accordance with a state law.20. A computer program product comprising a non-transitory computeruseable medium including a computer readable program, wherein thecomputer readable program when executed on a computer causes thecomputer to: receive private patient information associated with ahealth care information system of a provider; determine that the privatepatient information includes confidential data based on an indicator,wherein data is confidential data when the indicator associated with thedata indicates that the data is inaccessible to a health care entity,the health care entity having an authorized relationship with thepatient; receive a request from a user for accessing the confidentialdata; and determine whether the user is allowed to access theconfidential data.